PKI, or Public Key Infrastructure, is a set of operating system and application services that supports public key cryptography. Public key cryptography is an important technology for e-commerce, internet, intranet and other applications requiring “distributed security” (i.e., security in which the participants are not part of the same network and have no common security credentials). Specifically, public key cryptography provides two fundamental operations: encryption and signing. By encrypting electronic data, the goal is for the data to be read only by the intended party. With public key cryptography, a sender can encrypt a message using the specific public key corresponding to the receiver. In turn, only the receiver (using his or her private key) can decrypt the message.
On the other hand, signing is used to authenticate the identity of another party. Again, public key cryptography is involved, but in this instance a message may be encrypted by a sender's private key. Anyone can decrypt the message with the sender's corresponding public key, but the identity of the sender is established because the message could only have been encrypted by the sender's private key.
Public keys are typically packaged as digital certificates, which contain the public key, as well a set of other attributes such as the keyholder's name, what the keyholder is allowed to do, and under what circumstances the certificate is valid. The X.509 v3 digital certificate is an International Telecommunication Union (ITU) standard defining the format and content of digital certificates. The keyholder's attributes are cryptographically bound to the public key because the certificate is digitally signed by a Certificate Authority (CA) that issued it. The CA, or issuer, is a trusted entity associated with the keyholder; thus, the certificate's authenticity and correctness is vouched for by the issuer's signature.
In certain instances, however, the subject or keyholder identity carried in the digital certificate may not exactly match the keyholder's identity on a particular host system. For example, FIG. 1 illustrates an exemplary representation of an X.509 v3 digital certificate 10 and an exemplary system registry 12 for a host server. As can been seen from the subject identity 14 included in the digital certificate, the particular formatting thereof does not correspond to the subject identity 16 in the system registry, even though they are one and the same. In order to establish authorization and gain access, therefore, a flexible means has been developed to associate additional attributes to a digital certificate, in addition to the standard attributes. A host-identity mapping extension enables the coupling of a X.509 v3 digital certificate to a host application server. The host-identity mapping extension may include additional attributes therein to provide proof of identity possession (PIP). For instance, the PIP field can include the password which corresponds to the identity on the host server. If the password and user id are properly accompanied by an appropriate signature, then access to a host server may be achieved.
However, host-identity mapping extensions used in digital certificates are not without drawbacks. This is particularly the case when dealing with an external or third party CA. If the CA is run by an organization outside the host system, then the authenticating secret (password) is exposed to an outside agency which may not necessarily be trustworthy. If the integrity of the CA is compromised, then the password could be used to impersonate the keyholder on the host system. Yet, if the password is not embedded in the extension, the host server must then rely upon the CA to be trustworthy enough to verify the validity of the subject id, without proof of possession. It may be appropriate for the host system to honor the host-identity mapping extension of a digital certificate if the certificate is issued by a local CA, but not honor the extension if the certificate is issued by a public or third party CA. Because most PKIs understand only a binary trust value as applied to CAs (i.e., “trusted” or “not trusted”), the digital signature coupling with host identities can be problematic.